reconnect failing in 3.51.12

reconnect failing in 3.51.12

am 10.02.2007 00:54:39 von John Calcote

--=__Part4662C3AF.0__=
Content-Type: multipart/alternative; boundary="=__Part4662C3AF.1__="

--=__Part4662C3AF.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've got a linux daemon that logs to myodbc 3.51.12 through unixODBC driver manager. The first time my program receives a command it establishes an entire ODBC environment via the following (abbreviated) code:

int connect()
{
SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hsql);
SQLSetEnvAttr(hsql, SQL_ATTR_ODBC_VERSION, (void *)SQL_OV_ODBC3, 0);
SQLAllocHandle(SQL_HANDLE_DBC, hsql, &hdbc);
SQLConnect(hdbc, (SQLCHAR*)dsn, SQL_NTS, (SQLCHAR*)user, SQL_NTS, (SQLCHAR*)passwd, SQL_NTS);
SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
SQLPrepare(hstmt, primary_stmt, SQL_NTS);

for (i = 0; i < elemcount(pa); i++)
SQLBindParameter(hstmt, j++, SQL_PARAM_INPUT, pa[i].c_type, pa[i].s_type, pa[i].csize, 0, pa[i].pvp, 0, &ind[i]);
}

void disconnect()
{
if (hstmt != 0)
SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
if (hdbc != 0)
{
SQLDisconnect(hdbc);
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
}
if (hsql != 0)
SQLFreeHandle(SQL_HANDLE_ENV, hsql);
hstmt = hdbc = hsql = 0;
}
Of course, I check all of the error returns in the real code. The daemon monitors for intermittent request traffic and logs things to the database as requests come in. If there's an 8 hour delay between requests, the ODBC connection times out. I expect this condition in the log code as follows:

if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
{
disconnect();
if (connect() != 0)
return -1;
else if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
return -1;
}
My problem is that I cannot re-establish the connection once it's been broken like this. I get errors back from myodbc like this:

(a snippet from my daemon's log file)
[Wed Feb 7 15:26:32 2007] Entering main run loop...

(first request established initial connection)
[Wed Feb 7 15:27:48 2007] xdm_odbc: Connection established. [DSN=xdas;UID=root;PWD=;].

(second request - over 8 hours later - tries to re-establish connection)
[Fri Feb 9 02:52:56 2007] xdm_odbc: the ODBC driver reported -1 during SQLConnect:
[Fri Feb 9 02:52:56 2007] xdm_odbc: HYT00:1:2019:[unixODBC][MySQL][ODBC 3.51 Driver]Can't initialize character set latin1 (path: /usr/share/mysql/charsets/)
[Fri Feb 9 02:52:56 2007] xdm_odbc: ODBC Reconnect failed, error -1.
What am I doing wrong? It seems simple enough to me. I noticed on the mailing list that a few folks had trouble using SQLDriverConnect, so I switched to SQLConnect, and now I get other types of errors trying to reconnect - not the least of these are that my daemon segfaults down inside of libmyodbc with the following stack trace:

#0 0xb741dc5d in my_strcasecmp_8bit () from /usr/lib/mysql/libmysqlclient.so.15
#1 0xb741514d in get_charset_number () from /usr/lib/mysql/libmysqlclient.so.15
#2 0xb74151ab in get_charset_by_csname () from /usr/lib/mysql/libmysqlclient.so.15
#3 0xb74320ec in mysql_real_connect () from /usr/lib/mysql/libmysqlclient.so.15
#4 0xb753c15a in SQLConnect (hdbc=0x807fe78, szDSN=0xb7d8df51, cbDSN=-3,
szUID=0xb7d8e270, cbUID=-3, szAuthStr=0xb7d8e1f0, cbAuthStr=-3) at connect.c:253
#5 0xb7d9d394 in SQLConnect (connection_handle=0x80616f0,
server_name=0xb7d8e2f0, name_length1=-3, user_name=0xb7d8e270,
name_length2=-3, authentication=0xb7d8e1f0, name_length3=-3) at SQLConnect.c:3820
#6 0xb7f63c23 in sql_connect () at xdm_odbc.c:322
#7 0xb7f6411a in xdm_append (msg=0x80776a9, msgsz=272) at xdm_odbc.c:394
#8 0x0804a3cf in xdasd_logger_append (msg=0x8077598, msgsz=272) at xdasd_logger.c:175
#9 0x0804a0e2 in bg_logger (unused=0x0) at xdasd_lcache.c:90
#10 0xb7f3b34b in start_thread () from /lib/libpthread.so.0
#11 0xb7ed365e in clone () from /lib/libc.so.6
Any ideas would be appreciated.

Thanks,
John


-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.

--=__Part4662C3AF.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML


">


I've got a linux daemon that logs to myodbc 3.51.12 through unixODBC =
driver manager. The first time my program receives a command it establishes=
an entire ODBC environment via the following (abbreviated) code: >
 

   int connect()

   {

      SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HAND=
LE, &hsql);

      SQLSetEnvAttr(hsql, SQL_ATTR_ODBC_VERSION, =
(void *)SQL_OV_ODBC3, 0);

      SQLAllocHandle(SQL_HANDLE_DBC, hsql, =
&hdbc);

      SQLConnect(hdbc, (SQLCHAR*)dsn, SQL_NTS,&nbs=
p;(SQLCHAR*)user, SQL_NTS, (SQLCHAR*)passwd, SQL_NTS);

      SQLAllocHandle(SQL_HANDLE_STMT, hdbc, =
&hstmt);

      SQLPrepare(hstmt, primary_stmt, SQL_NTS); IV>
 

      for (i =3D 0; i < elemcount(pa); =
i++)

         SQLBindParameter(hstmt, j++, =
SQL_PARAM_INPUT, pa[i].c_type, pa[i].s_type, pa[i].csize, 0, =
pa[i].pvp, 0, &ind[i]);

   }

 

   void disconnect()
   {
   =
   if (hstmt !=3D 0)
       &nbs=
p; SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
      if =
(hdbc !=3D 0)
      {
     &n=
bsp;   SQLDisconnect(hdbc);
      &nb=
sp;  SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
     =
}
      if (hsql !=3D 0)
    &nbs=
p;    SQLFreeHandle(SQL_HANDLE_ENV, hsql);
   =
   hstmt =3D hdbc =3D hsql =3D 0;
   }

Of course, I check all of the error returns in the real code. The =
daemon monitors for intermittent request traffic and logs things to the =
database as requests come in. If there's an 8 hour delay between requests, =
the ODBC connection times out. I expect this condition in the log code as =
follows:

 

   if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
   =
{
      disconnect();
   &nbs=
p;  if (connect() !=3D 0)
       =
;  return -1;
      else if (!SQL_SUCCEEDE=
D(SQLExecute(hstmt)))
        &n=
bsp;return -1;
   }

My problem is that I cannot re-establish the connection once it's =
been broken like this. I get errors back from myodbc like this:

 

   (a snippet from my daemon's log file)

   [Wed Feb  7 15:26:32 2007] Entering main run =
loop...

 

   (first request established initial connection)<=
BR>   [Wed Feb  7 15:27:48 2007] xdm_odbc: Connection =
established. [DSN=3Dxdas;UID=3Droot;PWD=3D;].

 

   (second request - over 8 hours later - tries =
to re-establish connection)
   [Fri Feb  9 02:52:56 =
2007] xdm_odbc: the ODBC driver reported -1 during SQLConnect:
 &nb=
sp; [Fri Feb  9 02:52:56 2007] xdm_odbc: HYT00:1:2019:[unixODBC][MySQL=
][ODBC 3.51 Driver]Can't initialize character set latin1 (path: /usr/share/=
mysql/charsets/)
   [Fri Feb  9 02:52:56 2007] xdm_odbc: =
ODBC Reconnect failed, error -1.

What am I doing wrong? It seems simple enough to me. I noticed on the =
mailing list that a few folks had trouble using SQLDriverConnect, so I =
switched to SQLConnect, and now I get other types of errors trying to =
reconnect - not the least of these are that my daemon segfaults down =
inside of libmyodbc with the following stack trace:

 

#0  0xb741dc5d in my_strcasecmp_8bit () from /usr/lib/mysql/libmy=
sqlclient.so.15
#1  0xb741514d in get_charset_number () from =
/usr/lib/mysql/libmysqlclient.so.15
#2  0xb74151ab in get_charset_b=
y_csname () from /usr/lib/mysql/libmysqlclient.so.15
#3  0xb74320ec=
in mysql_real_connect () from /usr/lib/mysql/libmysqlclient.so.15
#4&nb=
sp; 0xb753c15a in SQLConnect (hdbc=3D0x807fe78, szDSN=3D0xb7d8df51, =
cbDSN=3D-3,
    szUID=3D0xb7d8e270, cbUID=3D-3, =
szAuthStr=3D0xb7d8e1f0, cbAuthStr=3D-3) at connect.c:253
#5  =
0xb7d9d394 in SQLConnect (connection_handle=3D0x80616f0,
  &nb=
sp; server_name=3D0xb7d8e2f0, name_length1=3D-3, user_name=3D0xb7d8e270, >    name_length2=3D-3, authentication=3D0xb7d8e1f0, =
name_length3=3D-3) at SQLConnect.c:3820
#6  0xb7f63c23 in =
sql_connect () at xdm_odbc.c:322
#7  0xb7f6411a in xdm_append =
(msg=3D0x80776a9, msgsz=3D272) at xdm_odbc.c:394
#8  0x0804a3cf in =
xdasd_logger_append (msg=3D0x8077598, msgsz=3D272) at xdasd_logger.c:175 >#9  0x0804a0e2 in bg_logger (unused=3D0x0) at xdasd_lcache.c:90
#1=
0 0xb7f3b34b in start_thread () from /lib/libpthread.so.0
#11 0xb7ed365e=
in clone () from /lib/libc.so.6

Any ideas would be appreciated.

 

Thanks,

John

 

 
-----
John Calcote (jcalcote@novell.com)
Sr. =
Software Engineeer
Novell, Inc.


--=__Part4662C3AF.1__=--

--=__Part4662C3AF.0__=
Content-Type: text/plain; name="John Calcote.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="John Calcote.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Joh n Calcote=3D0A=
=3D
PRV-H-511=3D0A=3D
Provo
END:VCARD



--=__Part4662C3AF.0__=
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
--=__Part4662C3AF.0__=--

RE: reconnect failing in 3.51.12

am 10.02.2007 04:29:24 von Lawson Cronlund

------=_NextPart_000_0001_01C74C88.FEA507C0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,



Lawson Cronlundlawson@vrtinc.com

+1(480)308-0641 (voice)

+1(602)996-0376 (fax)



_____

From: John Calcote [mailto:jcalcote@novell.com]
Sent: Friday, February 09, 2007 4:55 PM
To: myodbc@lists.mysql.com
Subject: reconnect failing in 3.51.12



I've got a linux daemon that logs to myodbc 3.51.12 through unixODBC driver
manager. The first time my program receives a command it establishes an
entire ODBC environment via the following (abbreviated) code:



int connect()

{

SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hsql);

SQLSetEnvAttr(hsql, SQL_ATTR_ODBC_VERSION, (void *)SQL_OV_ODBC3, 0);

SQLAllocHandle(SQL_HANDLE_DBC, hsql, &hdbc);

SQLConnect(hdbc, (SQLCHAR*)dsn, SQL_NTS, (SQLCHAR*)user, SQL_NTS,
(SQLCHAR*)passwd, SQL_NTS);

SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);

SQLPrepare(hstmt, primary_stmt, SQL_NTS);



for (i = 0; i < elemcount(pa); i++)

SQLBindParameter(hstmt, j++, SQL_PARAM_INPUT, pa[i].c_type,
pa[i].s_type, pa[i].csize, 0, pa[i].pvp, 0, &ind[i]);

}



void disconnect()
{
if (hstmt != 0)
SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
if (hdbc != 0)
{
SQLDisconnect(hdbc);
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
}
if (hsql != 0)
SQLFreeHandle(SQL_HANDLE_ENV, hsql);
hstmt = hdbc = hsql = 0;
}

Of course, I check all of the error returns in the real code. The daemon
monitors for intermittent request traffic and logs things to the database as
requests come in. If there's an 8 hour delay between requests, the ODBC
connection times out. I expect this condition in the log code as follows:



if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
{
disconnect();
if (connect() != 0)
return -1;
else if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
return -1;
}

My problem is that I cannot re-establish the connection once it's been
broken like this. I get errors back from myodbc like this:



(a snippet from my daemon's log file)

[Wed Feb 7 15:26:32 2007] Entering main run loop...



(first request established initial connection)
[Wed Feb 7 15:27:48 2007] xdm_odbc: Connection established.
[DSN=xdas;UID=root;PWD=;].



(second request - over 8 hours later - tries to re-establish connection)
[Fri Feb 9 02:52:56 2007] xdm_odbc: the ODBC driver reported -1 during
SQLConnect:
[Fri Feb 9 02:52:56 2007] xdm_odbc: HYT00:1:2019:[unixODBC][MySQL][ODBC
3.51 Driver]Can't initialize character set latin1 (path:
/usr/share/mysql/charsets/)
[Fri Feb 9 02:52:56 2007] xdm_odbc: ODBC Reconnect failed, error -1.

What am I doing wrong? It seems simple enough to me. I noticed on the
mailing list that a few folks had trouble using SQLDriverConnect, so I
switched to SQLConnect, and now I get other types of errors trying to
reconnect - not the least of these are that my daemon segfaults down inside
of libmyodbc with the following stack trace:



#0 0xb741dc5d in my_strcasecmp_8bit () from
/usr/lib/mysql/libmysqlclient.so.15
#1 0xb741514d in get_charset_number () from
/usr/lib/mysql/libmysqlclient.so.15
#2 0xb74151ab in get_charset_by_csname () from
/usr/lib/mysql/libmysqlclient.so.15
#3 0xb74320ec in mysql_real_connect () from
/usr/lib/mysql/libmysqlclient.so.15
#4 0xb753c15a in SQLConnect (hdbc=0x807fe78, szDSN=0xb7d8df51, cbDSN=-3,
szUID=0xb7d8e270, cbUID=-3, szAuthStr=0xb7d8e1f0, cbAuthStr=-3) at
connect.c:253
#5 0xb7d9d394 in SQLConnect (connection_handle=0x80616f0,
server_name=0xb7d8e2f0, name_length1=-3, user_name=0xb7d8e270,
name_length2=-3, authentication=0xb7d8e1f0, name_length3=-3) at
SQLConnect.c:3820
#6 0xb7f63c23 in sql_connect () at xdm_odbc.c:322
#7 0xb7f6411a in xdm_append (msg=0x80776a9, msgsz=272) at xdm_odbc.c:394
#8 0x0804a3cf in xdasd_logger_append (msg=0x8077598, msgsz=272) at
xdasd_logger.c:175
#9 0x0804a0e2 in bg_logger (unused=0x0) at xdasd_lcache.c:90
#10 0xb7f3b34b in start_thread () from /lib/libpthread.so.0
#11 0xb7ed365e in clone () from /lib/libc.so.6

Any ideas would be appreciated.



Thanks,

John





-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.


------=_NextPart_000_0001_01C74C88.FEA507C0--

RE: reconnect failing in 3.51.12

am 10.02.2007 04:32:10 von Lawson Cronlund

------=_NextPart_000_0009_01C74C89.5FFEE7C0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

John,

My approach to this problem was to keep track of the amount of time between
queries to the MySQL database. If it got to be more than 4 hours
(approximately, I made a "do nothing" query to the database to reset its
no-activity timer.

Kind of dirty but it's worked for over a year now.

Regards,



Lawson Cronlund

lawson@vrtinc.com

+1(480)308-0641 (voice)

+1(602)996-0376 (fax)



_____

From: John Calcote [mailto:jcalcote@novell.com]
Sent: Friday, February 09, 2007 4:55 PM
To: myodbc@lists.mysql.com
Subject: reconnect failing in 3.51.12



I've got a linux daemon that logs to myodbc 3.51.12 through unixODBC driver
manager. The first time my program receives a command it establishes an
entire ODBC environment via the following (abbreviated) code:



int connect()

{

SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hsql);

SQLSetEnvAttr(hsql, SQL_ATTR_ODBC_VERSION, (void *)SQL_OV_ODBC3, 0);

SQLAllocHandle(SQL_HANDLE_DBC, hsql, &hdbc);

SQLConnect(hdbc, (SQLCHAR*)dsn, SQL_NTS, (SQLCHAR*)user, SQL_NTS,
(SQLCHAR*)passwd, SQL_NTS);

SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);

SQLPrepare(hstmt, primary_stmt, SQL_NTS);



for (i = 0; i < elemcount(pa); i++)

SQLBindParameter(hstmt, j++, SQL_PARAM_INPUT, pa[i].c_type,
pa[i].s_type, pa[i].csize, 0, pa[i].pvp, 0, &ind[i]);

}



void disconnect()
{
if (hstmt != 0)
SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
if (hdbc != 0)
{
SQLDisconnect(hdbc);
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
}
if (hsql != 0)
SQLFreeHandle(SQL_HANDLE_ENV, hsql);
hstmt = hdbc = hsql = 0;
}

Of course, I check all of the error returns in the real code. The daemon
monitors for intermittent request traffic and logs things to the database as
requests come in. If there's an 8 hour delay between requests, the ODBC
connection times out. I expect this condition in the log code as follows:



if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
{
disconnect();
if (connect() != 0)
return -1;
else if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
return -1;
}

My problem is that I cannot re-establish the connection once it's been
broken like this. I get errors back from myodbc like this:



(a snippet from my daemon's log file)

[Wed Feb 7 15:26:32 2007] Entering main run loop...



(first request established initial connection)
[Wed Feb 7 15:27:48 2007] xdm_odbc: Connection established.
[DSN=xdas;UID=root;PWD=;].



(second request - over 8 hours later - tries to re-establish connection)
[Fri Feb 9 02:52:56 2007] xdm_odbc: the ODBC driver reported -1 during
SQLConnect:
[Fri Feb 9 02:52:56 2007] xdm_odbc: HYT00:1:2019:[unixODBC][MySQL][ODBC
3.51 Driver]Can't initialize character set latin1 (path:
/usr/share/mysql/charsets/)
[Fri Feb 9 02:52:56 2007] xdm_odbc: ODBC Reconnect failed, error -1.

What am I doing wrong? It seems simple enough to me. I noticed on the
mailing list that a few folks had trouble using SQLDriverConnect, so I
switched to SQLConnect, and now I get other types of errors trying to
reconnect - not the least of these are that my daemon segfaults down inside
of libmyodbc with the following stack trace:



#0 0xb741dc5d in my_strcasecmp_8bit () from
/usr/lib/mysql/libmysqlclient.so.15
#1 0xb741514d in get_charset_number () from
/usr/lib/mysql/libmysqlclient.so.15
#2 0xb74151ab in get_charset_by_csname () from
/usr/lib/mysql/libmysqlclient.so.15
#3 0xb74320ec in mysql_real_connect () from
/usr/lib/mysql/libmysqlclient.so.15
#4 0xb753c15a in SQLConnect (hdbc=0x807fe78, szDSN=0xb7d8df51, cbDSN=-3,
szUID=0xb7d8e270, cbUID=-3, szAuthStr=0xb7d8e1f0, cbAuthStr=-3) at
connect.c:253
#5 0xb7d9d394 in SQLConnect (connection_handle=0x80616f0,
server_name=0xb7d8e2f0, name_length1=-3, user_name=0xb7d8e270,
name_length2=-3, authentication=0xb7d8e1f0, name_length3=-3) at
SQLConnect.c:3820
#6 0xb7f63c23 in sql_connect () at xdm_odbc.c:322
#7 0xb7f6411a in xdm_append (msg=0x80776a9, msgsz=272) at xdm_odbc.c:394
#8 0x0804a3cf in xdasd_logger_append (msg=0x8077598, msgsz=272) at
xdasd_logger.c:175
#9 0x0804a0e2 in bg_logger (unused=0x0) at xdasd_lcache.c:90
#10 0xb7f3b34b in start_thread () from /lib/libpthread.so.0
#11 0xb7ed365e in clone () from /lib/libc.so.6

Any ideas would be appreciated.



Thanks,

John





-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.


------=_NextPart_000_0009_01C74C89.5FFEE7C0--

RE: reconnect failing in 3.51.12

am 10.02.2007 20:04:59 von John Calcote

--=__PartBF9B394B.0__=
Content-Type: multipart/alternative; boundary="=__PartBF9B394B.1__="

--=__PartBF9B394B.1__=
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Lawson,
=20
Thanks for the feedback.=20
=20
I had a horrible feeling it might come down to something like this. :) If =
you don't mind, I'll hold out for a few more answers, just in case - we =
might both learn something. But in the end, I'll have to do what you =
suggest if the folks at MySQL don't see the need to fix the issue - or at =
least give us a decent work-around.
=20
Regards,
=20
John
=20
-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.


>>> On Fri, Feb 9, 2007 at 8:32 PM, in message <000801c74cc4$0c5dbfc0$6500=
a8c0@winxppro>, "Lawson Cronlund" wrote:

John,
My approach to this problem was to keep track of the amount of time =
between queries to the MySQL database. If it got to be more than 4 hours =
(approximately, I made a *do nothing* query to the database to reset its =
no-activity timer.
Kind of dirty but it*s worked for over a year now.
Regards,
=20

Lawson Cronlund
lawson@vrtinc.com
+1(480)308-0641 (voice)
+1(602)996-0376 (fax)
=20


From:John Calcote [mailto:jcalcote@novell.com]=20
Sent: Friday, February 09, 2007 4:55 PM
To: myodbc@lists.mysql.com=20
Subject: reconnect failing in 3.51.12

=20

I've got a linux daemon that logs to myodbc 3.51.12 through unixODBC =
driver manager. The first time my program receives a command it establishes=
an entire ODBC environment via the following (abbreviated) code:

=20

int connect()

{

SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hsql);

SQLSetEnvAttr(hsql, SQL_ATTR_ODBC_VERSION, (void *)SQL_OV_ODBC3, 0);

SQLAllocHandle(SQL_HANDLE_DBC, hsql, &hdbc);

SQLConnect(hdbc, (SQLCHAR*)dsn, SQL_NTS, (SQLCHAR*)user, SQL_NTS, =
(SQLCHAR*)passwd, SQL_NTS);

SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);

SQLPrepare(hstmt, primary_stmt, SQL_NTS);

=20

for (i =3D 0; i < elemcount(pa); i++)

SQLBindParameter(hstmt, j++, SQL_PARAM_INPUT, pa[i].c_type, =
pa[i].s_type, pa[i].csize, 0, pa[i].pvp, 0, &ind[i]);

}

=20

void disconnect()
{
if (hstmt !=3D 0)
SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
if (hdbc !=3D 0)
{
SQLDisconnect(hdbc);
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
}
if (hsql !=3D 0)
SQLFreeHandle(SQL_HANDLE_ENV, hsql);
hstmt =3D hdbc =3D hsql =3D 0;
}

Of course, I check all of the error returns in the real code. The daemon =
monitors for intermittent request traffic and logs things to the database =
as requests come in. If there's an 8 hour delay between requests, the ODBC =
connection times out. I expect this condition in the log code as follows:

=20

if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
{
disconnect();
if (connect() !=3D 0)
return -1;
else if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
return -1;
}

My problem is that I cannot re-establish the connection once it's been =
broken like this. I get errors back from myodbc like this:

=20

(a snippet from my daemon's log file)

[Wed Feb 7 15:26:32 2007] Entering main run loop...

=20

(first request established initial connection)
[Wed Feb 7 15:27:48 2007] xdm_odbc: Connection established. [DSN=3Dxdas=
;UID=3Droot;PWD=3D;].

=20

(second request - over 8 hours later - tries to re-establish connection)=

[Fri Feb 9 02:52:56 2007] xdm_odbc: the ODBC driver reported -1 during =
SQLConnect:
[Fri Feb 9 02:52:56 2007] xdm_odbc: HYT00:1:2019:[unixODBC][MySQL][ODBC=
3.51 Driver]Can't initialize character set latin1 (path: /usr/share/mysql/=
charsets/)
[Fri Feb 9 02:52:56 2007] xdm_odbc: ODBC Reconnect failed, error -1.

What am I doing wrong? It seems simple enough to me. I noticed on the =
mailing list that a few folks had trouble using SQLDriverConnect, so I =
switched to SQLConnect, and now I get other types of errors trying to =
reconnect - not the least of these are that my daemon segfaults down =
inside of libmyodbc with the following stack trace:

=20

#0 0xb741dc5d in my_strcasecmp_8bit () from /usr/lib/mysql/libmysqlclient.=
so.15
#1 0xb741514d in get_charset_number () from /usr/lib/mysql/libmysqlclient.=
so.15
#2 0xb74151ab in get_charset_by_csname () from /usr/lib/mysql/libmysqlclie=
nt.so.15
#3 0xb74320ec in mysql_real_connect () from /usr/lib/mysql/libmysqlclient.=
so.15
#4 0xb753c15a in SQLConnect (hdbc=3D0x807fe78, szDSN=3D0xb7d8df51, =
cbDSN=3D-3,
szUID=3D0xb7d8e270, cbUID=3D-3, szAuthStr=3D0xb7d8e1f0, cbAuthStr=3D-3)=
at connect.c:253
#5 0xb7d9d394 in SQLConnect (connection_handle=3D0x80616f0,
server_name=3D0xb7d8e2f0, name_length1=3D-3, user_name=3D0xb7d8e270,
name_length2=3D-3, authentication=3D0xb7d8e1f0, name_length3=3D-3) at =
SQLConnect.c:3820
#6 0xb7f63c23 in sql_connect () at xdm_odbc.c:322
#7 0xb7f6411a in xdm_append (msg=3D0x80776a9, msgsz=3D272) at xdm_odbc.c:3=
94
#8 0x0804a3cf in xdasd_logger_append (msg=3D0x8077598, msgsz=3D272) at =
xdasd_logger.c:175
#9 0x0804a0e2 in bg_logger (unused=3D0x0) at xdasd_lcache.c:90
#10 0xb7f3b34b in start_thread () from /lib/libpthread.so.0
#11 0xb7ed365e in clone () from /lib/libc.so.6

Any ideas would be appreciated.

=20

Thanks,

John

=20

=20

-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.

--=__PartBF9B394B.1__=
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML


">






Lawson,

 

Thanks for the feedback.

 

I had a horrible feeling it might come down to something like this. =
:) If you don't mind, I'll hold out for a few more answers, just in case - =
we might both learn something. But in the end, I'll have to do what you =
suggest if the folks at MySQL don't see the need to fix the issue - or at =
least give us a decent work-around.

 

Regards,

 

John

 

-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer<=
BR>Novell, Inc.


>>> On Fri, Feb 9, 2007 at  8:32 =
PM, in message <000801c74cc4$0c5dbfc0$6500a8c0@winxppro>, "Lawson =
Cronlund" <lawson@vrtinc.com> wrote:

#050505 1px solid; BACKGROUND-COLOR: #f3f3f3">

style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">John, pace prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office" =
/>


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">My approach to =
this problem was to keep track of the amount of time between queries to =
the MySQL database.  If it got to be more than 4 hours (approximately,=
I made a "do nothing" query to the database to reset its no-activity =
timer.


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Kind of dirty =
but it's worked for over a year now.


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Regards, :p>


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">  >



rosoft-com:office:smarttags" /> al color=3Dnavy size=3D2> FONT-FAMILY: Arial">Lawson Cronlund color=3Dnavy>


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"> o:lawson@vrtinc.com">lawson@vrtinc.com=


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">+1(480)308-0641 =
(voice)
o:p>


style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">+1(602)996-0376 =
(fax)
p>


<=
SPAN style=3D"FONT-SIZE: 12pt; COLOR: navy"> 
=



align=3Dcenter> SIZE: 12pt">



size=3D2> Tahoma">From: style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma"> John Calcote [mailto:jcalco=
te@novell.com]
Sent: =
Friday, February 09, 2007 4:55 PM
bold">To: myodbc@lists.mysql.com
T: bold">Subject: reconnect failing in 3.51.12
>


style=3D"FONT-SIZE: 12pt"> 



size=3D2>I've got a =
linux daemon that logs to myodbc 3.51.12 through unixODBC driver manager. =
The first time my program receives a command it establishes an entire ODBC =
environment via the following (abbreviated) code:
ONT>



size=3D2>  o:p>



size=3D2>   =
int connect()



size=3D2>   =
{



size=3D2>   =
   SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &hsql); p>



size=3D2>   =
   SQLSetEnvAttr(hsql, SQL_ATTR_ODBC_VERSION, (void *)SQL_OV_ODBC=
3, 0);



size=3D2>   =
   SQLAllocHandle(SQL_HANDLE_DBC, hsql, &hdbc); PAN>



size=3D2>   =
   SQLConnect(hdbc, (SQLCHAR*)dsn, SQL_NTS, (SQLCHAR*)user, =
SQL_NTS, (SQLCHAR*)passwd, SQL_NTS);



size=3D2>   =
   SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);<=
/SPAN>



size=3D2>   =
   SQLPrepare(hstmt, primary_stmt, SQL_NTS);
ONT>



size=3D2>  o:p>



size=3D2>   =
   for (i =3D 0; i < elemcount(pa); i++)
NT>



size=3D2>   =
      SQLBindParameter(hstmt, j++, SQL_PARAM_INPUT,&nbs=
p;pa[i].c_type, pa[i].s_type, pa[i].csize, 0, pa[i].pvp, 0, &ind[i]); :p>



size=3D2>   =
}



size=3D2>  o:p>



size=3D2>   =
void disconnect()
   {
      if (hstmt =
!=3D 0)
         SQLFreeHandle(SQL_HA=
NDLE_STMT, hstmt);
      if (hdbc !=3D 0)
 &=
nbsp;    {
         =
SQLDisconnect(hdbc);
         =
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
      =
}
      if (hsql !=3D 0)
     =
;    SQLFreeHandle(SQL_HANDLE_ENV, hsql);
   =
   hstmt =3D hdbc =3D hsql =3D 0;
   } PAN>



size=3D2>Of course, I =
check all of the error returns in the real code. The daemon monitors for =
intermittent request traffic and logs things to the database as requests =
come in. If there's an 8 hour delay between requests, the ODBC connection =
times out. I expect this condition in the log code as follows: SPAN>



size=3D2>  o:p>



size=3D2>   =
if (!SQL_SUCCEEDED(SQLExecute(hstmt)))
   {
  &nb=
sp;   disconnect();
      if =
(connect() !=3D 0)
         =
return -1;
      else if (!SQL_SUCCEEDED(SQLExe=
cute(hstmt)))
         retu=
rn -1;
   }



size=3D2>My problem =
is that I cannot re-establish the connection once it's been broken like =
this. I get errors back from myodbc like this:

=


size=3D2>  o:p>



size=3D2>   =
(a snippet from my daemon's log file)



size=3D2>   =
[Wed Feb  7 15:26:32 2007] Entering main run loop...
=



size=3D2>  o:p>



size=3D2>  &=
nbsp;(first request established initial connection)
   =
[Wed Feb  7 15:27:48 2007] xdm_odbc: Connection established. =
[DSN=3Dxdas;UID=3Droot;PWD=3D;].



size=3D2>  o:p>



size=3D2>   =
(second request - over 8 hours later - tries to re-establish =
connection)
   [Fri Feb  9 02:52:56 2007] xdm_odbc: the =
ODBC driver reported -1 during SQLConnect:
   [Fri Feb  =
9 02:52:56 2007] xdm_odbc: HYT00:1:2019:[unixODBC][MySQL][ODBC 3.51 =
Driver]Can't initialize character set latin1 (path: /usr/share/mysql/charse=
ts/)
   [Fri Feb  9 02:52:56 2007] xdm_odbc: ODBC =
Reconnect failed, error -1.



size=3D2>What am I =
doing wrong? It seems simple enough to me. I noticed on the mailing list =
that a few folks had trouble using SQLDriverConnect, so I switched to =
SQLConnect, and now I get other types of errors trying to reconnect - not =
the least of these are that my daemon segfaults down inside of libmyodbc =
with the following stack trace:



size=3D2>  o:p>



size=3D2>#0  =
0xb741dc5d in my_strcasecmp_8bit () from /usr/lib/mysql/libmysqlclient.so.1=
5
#1  0xb741514d in get_charset_number () from /usr/lib/mysql/libmy=
sqlclient.so.15
#2  0xb74151ab in get_charset_by_csname () from =
/usr/lib/mysql/libmysqlclient.so.15
#3  0xb74320ec in mysql_real_co=
nnect () from /usr/lib/mysql/libmysqlclient.so.15
#4  0xb753c15a =
in SQLConnect (hdbc=3D0x807fe78, szDSN=3D0xb7d8df51, cbDSN=3D-3,
 &=
nbsp;  szUID=3D0xb7d8e270, cbUID=3D-3, szAuthStr=3D0xb7d8e1f0, =
cbAuthStr=3D-3) at connect.c:253
#5  0xb7d9d394 in SQLConnect =
(connection_handle=3D0x80616f0,
    server_name=3D0xb7d8e=
2f0, name_length1=3D-3, user_name=3D0xb7d8e270,
    =
name_length2=3D-3, authentication=3D0xb7d8e1f0, name_length3=3D-3) at =
SQLConnect.c:3820
#6  0xb7f63c23 in sql_connect () at xdm_odbc.c:32=
2
#7  0xb7f6411a in xdm_append (msg=3D0x80776a9, msgsz=3D272) at =
xdm_odbc.c:394
#8  0x0804a3cf in xdasd_logger_append (msg=3D0x80775=
98, msgsz=3D272) at xdasd_logger.c:175
#9  0x0804a0e2 in bg_logger =
(unused=3D0x0) at xdasd_lcache.c:90
#10 0xb7f3b34b in start_thread () =
from /lib/libpthread.so.0
#11 0xb7ed365e in clone () from /lib/libc.so.6=



size=3D2>Any ideas =
would be appreciated.



size=3D2>  o:p>



size=3D2>Thanks,<=
/o:p>



size=3D2>John p>



size=3D2>  o:p>



size=3D2>  o:p>


size=3D2>-----
John=
Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, =
Inc.



--=__PartBF9B394B.1__=--

--=__PartBF9B394B.0__=
Content-Type: text/plain; name="John Calcote.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="John Calcote.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Joh n Calcote=3D0A=
=3D
PRV-H-511=3D0A=3D
Provo
END:VCARD



--=__PartBF9B394B.0__=
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
--=__PartBF9B394B.0__=--

RE: reconnect failing in 3.51.12

am 12.02.2007 18:41:43 von John Calcote

--=__Part9CB804C7.0__=
Content-Type: multipart/alternative; boundary="=__Part9CB804C7.1__="

--=__Part9CB804C7.1__=
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Oh, I completely understand the necessity for the timeout. Frankly, I'm =
surprised the default isn't more like 30 minutes rather than 8 hours. My =
problem is that I can't seem to (manually) reconnect within the process =
after a timeout without corrupting the process - ultimately causing either =
a failure to reconnect, or a segfault (and subsequent crash).
=20
John
=20
-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.


>>> On Sat, Feb 10, 2007 at 7:04 PM, in message <003701c74d80$ef84d100$650=
0a8c0@winxppro>, "Lawson Cronlund" wrote:

John,
My interpretation was that the no-activity timeout operation is actually a =
protection that should be in the MySQL server. It*s a protection that =
retires connections that are not properly terminated. If nothing else was =
done, in a poorly implemented system, connections might be left *hanging* =
with random failures on maximum allowed connections.
The documentation seems to say that this timeout interval can be set in =
the configuration file(s) but any changes that I made didn*t seem to =
affect the timeout interval * so I gave up and did the dirty implementation=
which could be viewed as a sort of watchdog to tell me if my application =
was messing up if the connection ever terminated unilaterally.
The result was that my application was improved since it led me to using =
the technique for the watchdog program in my application that monitors the =
alive/dead status of the other application programs in the system.
I guess what I*m saying is that I think that the no-activity connection =
timeout in MySQL is a good thing but I would have liked it if I could have =
found the method for changing the timeout value.
Regards,
=20

--=__Part9CB804C7.1__=
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML


">


Oh, I completely understand the necessity for the timeout. Frankly, =
I'm surprised the default isn't more like 30 minutes rather than 8 hours. =
My problem is that I can't seem to (manually) reconnect within the process =
after a timeout without corrupting the process - ultimately causing either =
a failure to reconnect, or a segfault (and subsequent crash).

 

John

 

-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer<=
BR>Novell, Inc.


>>> On Sat, Feb 10, 2007 at  7:04 =
PM, in message <003701c74d80$ef84d100$6500a8c0@winxppro>, "Lawson =
Cronlund" <lawson@vrtinc.com> wrote:

#050505 1px solid; BACKGROUND-COLOR: #f3f3f3">

style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">John, pace prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office" =
/>


style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">My interpretatio=
n was that the no-activity timeout operation is actually a protection that =
should be in the MySQL server.  It's a protection that retires =
connections that are not properly terminated.  If nothing else was =
done, in a poorly implemented system, connections might be left "hanging" =
with random failures on maximum allowed connections.
T>


style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">The documentatio=
n seems to say that this timeout interval can be set in the configuration =
file(s) but any changes that I made didn't seem to affect the timeout =
interval - so I gave up and did the dirty implementation which could be =
viewed as a sort of watchdog to tell me if my application was messing up =
if the connection ever terminated unilaterally.
>

style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">The result was =
that my application was improved since it led me to using the technique =
for the watchdog program in my application that monitors the alive/dead =
status of the other application programs in the system.
FONT>


style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">I guess what =
I'm saying is that I think that the no-activity connection timeout in =
MySQL is a good thing but I would have liked it if I could have found the =
method for changing the timeout value.


style=3D"FONT-SIZE: 12pt; COLOR: navy; FONT-FAMILY: Arial">Regards, :p>


10pt; FONT-FAMILY: Tahoma"> 

=


--=__Part9CB804C7.1__=--

--=__Part9CB804C7.0__=
Content-Type: text/plain; name="John Calcote.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="John Calcote.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Joh n Calcote=3D0A=
=3D
PRV-H-511=3D0A=3D
Provo
END:VCARD



--=__Part9CB804C7.0__=
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
--=__Part9CB804C7.0__=--

Re: reconnect failing in 3.51.12

am 12.02.2007 20:42:35 von Jordan Bradford

Stay-alive messages definitely have their place.

I have a serial port device that times out after one _second_ of
inactivity, so I use a timer to send it a specific message to keep the
port open.

Re: the process' crashing, perhaps very few people try to keep a
connection open for so long, so fixing the bug isn't worth the effort .
.. . especially since a workaround is to "do nothing" once in a while.

-- Jordan Bradford
----------------------------
BrownBoots Interactive, Inc.
108 South Main St.
Fond du Lac, WI 54935
920-906-9175
http://www.brownboots.com/


John Calcote wrote:
> Oh, I completely understand the necessity for the timeout. Frankly, I'm
> surprised the default isn't more like 30 minutes rather than 8 hours. My
> problem is that I can't seem to (manually) reconnect within the process
> after a timeout without corrupting the process - ultimately causing
> either a failure to reconnect, or a segfault (and subsequent crash).
>
> John
>
> -----
> John Calcote (jcalcote@novell.com)
> Sr. Software Engineeer
> Novell, Inc.
>
>
>>>> On Sat, Feb 10, 2007 at 7:04 PM, in message
> <003701c74d80$ef84d100$6500a8c0@winxppro>, "Lawson Cronlund"
> wrote:
>
> John,
>
> My interpretation was that the no-activity timeout operation is actually
> a protection that should be in the MySQL server. It's a protection that
> retires connections that are not properly terminated. If nothing else
> was done, in a poorly implemented system, connections might be left
> "hanging" with random failures on maximum allowed connections.
>
> The documentation seems to say that this timeout interval can be set in
> the configuration file(s) but any changes that I made didn't seem to
> affect the timeout interval - so I gave up and did the dirty
> implementation which could be viewed as a sort of watchdog to tell me if
> my application was messing up if the connection ever terminated
> unilaterally.
>
> The result was that my application was improved since it led me to using
> the technique for the watchdog program in my application that monitors
> the alive/dead status of the other application programs in the system.
>
> I guess what I'm saying is that I think that the no-activity connection
> timeout in MySQL is a good thing but I would have liked it if I could
> have found the method for changing the timeout value.
>
> Regards,
>
>
>
>
> ------------------------------------------------------------ ------------
>
> BEGIN:VCARD
> VERSION:2.1
> X-GWTYPE:USER
> FN:John Calcote
> TEL;WORK:1-801-861-7517
> ORG:;Unified Identity System Eng TE
> TEL;PREF;FAX:801/861-2292
> EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
> N:Calcote;John;;Sr. Software Engineer
> TITLE:Sr. Software Engineer
> ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
> LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:John Calcote=0A=
> PRV-H-511=0A=
> Provo
> END:VCARD
>
>
>
>
> ------------------------------------------------------------ ------------
>
>

--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org

RE: reconnect failing in 3.51.12

am 13.02.2007 00:08:38 von John Calcote

--=__Part684CF066.0__=
Content-Type: multipart/alternative; boundary="=__Part684CF066.1__="

--=__Part684CF066.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Just wanted everyone to know the resolution to this problem. There's an option that can be specified in the (unixODBC) odbc.ini file to enable an option called "auto-reconnect". This option supposedly allows transparent reconnection with a few caveats.

(/etc/unixODBC/odbc.ini)
...
options = 4194304
...

The value 4194304 is decimal for the hex value 0x400000, which makes a little more sense - it's a bit flag that indicates an option to the myodbc driver.

Using this option, my ODBC client app no longer crashes (yet). To me this is quirky behavior anyway because this option should not be related to the way I was reconnecting anyway. In reality, it's a work-around - allow the underlying driver to reconnect rather than doing it in the app.

I'll let you all know if this status changes.

Thanks for the suggestions,
John



-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.

--=__Part684CF066.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML


">


Just wanted everyone to know the resolution to this problem. There's =
an option that can be specified in the (unixODBC) odbc.ini file to enable =
an option called "auto-reconnect". This option supposedly allows transparen=
t reconnection with a few caveats.

 

   (/etc/unixODBC/odbc.ini)

   ...

   options =3D 4194304

   ...

 

The value 4194304 is decimal for the hex value 0x400000, which makes =
a little more sense - it's a bit flag that indicates an option to the =
myodbc driver.

 

Using this option, my ODBC client app no longer crashes (yet). To me =
this is quirky behavior anyway because this option should not be related =
to the way I was reconnecting anyway. In reality, it's a work-around - =
allow the underlying driver to reconnect rather than doing it in the =
app.

 

I'll let you all know if this status changes.

 

Thanks for the suggestions,

John


 

 
-----
John Calcote (jcalcote@novell.com)
Sr. =
Software Engineeer
Novell, Inc.


--=__Part684CF066.1__=--

--=__Part684CF066.0__=
Content-Type: text/plain; name="John Calcote.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="John Calcote.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Joh n Calcote=3D0A=
=3D
PRV-H-511=3D0A=3D
Provo
END:VCARD



--=__Part684CF066.0__=
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
--=__Part684CF066.0__=--

RE: reconnect failing in 3.51.12

am 13.02.2007 22:14:32 von John Calcote

--=__PartFDD96728.0__=
Content-Type: multipart/alternative; boundary="=__PartFDD96728.1__="

--=__PartFDD96728.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

A final note on this issue - I noticed I didn't have the problem at all on my SuSE 10.2 machine.

In order to truely keep my ODBC client app from crashing during reconnect, I had to upgrade to the following revisions of rpm packages on my SuSE 10.1 box:


unixODBC-2.2.12-13.i586.rpm (from 2.2.11-19)
mysql-5.0.26-12.i586.rpm (from 5.0.18-20.8)
mysql-client-5.0.26-12.i586.rpm (from 5.0.18-16)
mysql-shared-5.0.26-12.i586.rpm (from 5.0.18-16)
MyODBC-unixODBC-3.51.12-33 (from 3.51.12-11)


The upgrade of unixODBC did nothing. Upgrading to mysql 5.0.26 and MyODBC 3.51.12-33 is what fixed the problem for me. I'm now able to completely reconnect with no trouble.

I checked the ChangeLog on MyODBC 3.51.12-33 - apparently the only difference between 3.51.12-11 and 3.51.12-33 is that make -j was used to build (multi-threaded make). Should have been a harmless build process change. I believe ultimately it made no difference.

I'm guessing the problem was fixed between mysql 5.0.18 and 5.0.26.

Question: Why couldn't someone from MySQL have told me this? It's not like there's a lot of traffic on this list. Don't they monitor?

John

-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.


>>> On Mon, Feb 12, 2007 at 4:08 PM, in message <45D09106.37FF.0081.0@novell.com>, "John Calcote" wrote:
Just wanted everyone to know the resolution to this problem. There's an option that can be specified in the (unixODBC) odbc.ini file to enable an option called "auto-reconnect". This option supposedly allows transparent reconnection with a few caveats.

(/etc/unixODBC/odbc.ini)
...
options = 4194304
...

The value 4194304 is decimal for the hex value 0x400000, which makes a little more sense - it's a bit flag that indicates an option to the myodbc driver.

Using this option, my ODBC client app no longer crashes (yet). To me this is quirky behavior anyway because this option should not be related to the way I was reconnecting anyway. In reality, it's a work-around - allow the underlying driver to reconnect rather than doing it in the app.

I'll let you all know if this status changes.

Thanks for the suggestions,
John



-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.

--=__PartFDD96728.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML


">


A final note on this issue - I noticed I didn't have the problem =
at all on my SuSE 10.2 machine.

 

In order to truely keep my ODBC client app from crashing during =
reconnect, I had to upgrade to the following revisions of rpm =
packages on my SuSE 10.1 box:

 

 

   unixODBC-2.2.12-13.i586.rpm (from 2.2.11-19)
 &nb=
sp; mysql-5.0.26-12.i586.rpm (from 5.0.18-20.8)
   mysql-clien=
t-5.0.26-12.i586.rpm (from 5.0.18-16)
   mysql-shared-5.0.26-1=
2.i586.rpm (from 5.0.18-16)
   MyODBC-unixODBC-3.51.12-33 =
(from 3.51.12-11)

 

 

The upgrade of unixODBC did nothing. Upgrading to mysql 5.0.26 and =
MyODBC 3.51.12-33 is what fixed the problem for me. I'm now able to =
completely reconnect with no trouble.

 

I checked the ChangeLog on MyODBC 3.51.12-33 - apparently the only =
difference between 3.51.12-11 and 3.51.12-33 is that make -j was used to =
build (multi-threaded make). Should have been a harmless build process =
change. I believe ultimately it made no difference.

 

I'm guessing the problem was fixed between mysql 5.0.18 and 5.0.26. IV>
 

Question: Why couldn't someone from MySQL have told me this? It's not =
like there's a lot of traffic on this list. Don't they monitor?

 

John

 

-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer<=
BR>Novell, Inc.


>>> On Mon, Feb 12, 2007 at  4:08 =
PM, in message <45D09106.37FF.0081.0@novell.com>, "John Calcote" =
<jcalcote@novell.com> wrote:

#050505 1px solid; BACKGROUND-COLOR: #f3f3f3">
Just wanted everyone to know the resolution to this problem. There's =
an option that can be specified in the (unixODBC) odbc.ini file to enable =
an option called "auto-reconnect". This option supposedly allows transparen=
t reconnection with a few caveats.

 

   (/etc/unixODBC/odbc.ini)

   ...

   options =3D 4194304

   ...

 

The value 4194304 is decimal for the hex value 0x400000, which makes =
a little more sense - it's a bit flag that indicates an option to the =
myodbc driver.

 

Using this option, my ODBC client app no longer crashes (yet). To me =
this is quirky behavior anyway because this option should not be related =
to the way I was reconnecting anyway. In reality, it's a work-around - =
allow the underlying driver to reconnect rather than doing it in the =
app.

 

I'll let you all know if this status changes.

 

Thanks for the suggestions,

John


 

 
-----
John Calcote (jcalcote@novell.com)
Sr. =
Software Engineeer
Novell, Inc.


--=__PartFDD96728.1__=--

--=__PartFDD96728.0__=
Content-Type: text/plain; name="John Calcote.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="John Calcote.vcf"

BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:John Calcote
TEL;WORK:1-801-861-7517
ORG:;Unified Identity System Eng TE
TEL;PREF;FAX:801/861-2292
EMAIL;WORK;PREF;NGW:JCALCOTE@novell.com
N:Calcote;John;;Sr. Software Engineer
TITLE:Sr. Software Engineer
ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=3DQUOTED-PRINTABLE:Joh n Calcote=3D0A=
=3D
PRV-H-511=3D0A=3D
Provo
END:VCARD



--=__PartFDD96728.0__=
Content-Type: text/plain; charset=us-ascii


--
MySQL ODBC Mailing List
For list archives: http://lists.mysql.com/myodbc
To unsubscribe: http://lists.mysql.com/myodbc?unsub=gcdmo-myodbc@m.gmane.org
--=__PartFDD96728.0__=--